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I (57) Abstract 



The invention provides for the first time a process for testing 
classes of an object-oriented program. Classes are tested by causing 
the tests interactively to input test commands with their method calls. 
It is also possible to check the test results interactively. Testability is 
obtained in that the necessary call parameters are found beforehand for 
all the methods permitted in the class and precautions are taken in the 
computer store to store and alter the possible parameters. The advantage 
is that testing can be performed interactively and not, as previously, in 
that the test program had to be once more corrected, translated and fixed 
after test evaluation, which took a great deal of time. The invention can 
advantageously be used in the development of communication software. 

(57) Zusammenlassung 

Mit der Erfindung wird erstmals cin Verfahren zum Testcn von 
Klassen eines objektorienticrtcn Programmes zur VerfUgung gestcllL 
Klassen werden gctestet, indem vom Tester Testkommandos mit 
deaen Methodcnaufrufe mdglich sind, interaktiv eingegeben werden. 
die Obcrprufung der Teste rgebnisse ist ebcnfalls interaktiv mdglich. 
Erreicht wird die Testbarkeit dadurch, dafl vorab fUr alJe in der 
Klasse erlaubten Methoden, die crfordcrlichen Aufrufparametcr ermitelt 
werden, und daB im Rechnerspeicher Vorkehrungcn getroffen werden, 
um die moglichcn Parameter abzuspcichern und zu verandern. Der 
Vortcil besteht darin, daS interaktiv getcstet werden kann, und nicht, wic 
bisher ublich das Tcstprogramm nach derTestauswcnung zeitaufwehdig 
crneut korrigiert abersetzt und gebunden werden muB. Vorteilhaft 
kann die Erfindung bei der En twicklung von Kommunikations- Software 
eingesetzt werden. 
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Verfahren zum Testen mindestens einer Klasse eines 
objektorientierten Programmes auf einem Rechner 

Hit dem zunehmendem Umfang von Systemlosungen im Rahmen von 
industriellen Grofiprojekten, wachst auch der Beitrag den die 
Software zur Losung liefert. Damit man groSe Sof twareproj ekte 
effizient abwickeln kann, hat es sich als vorteilhaft erwiesen, 
diese Pro j ekte in Teilprojekte zu unterteilen und einzelne 
Programme modular zu erstellen. Ein nicht unwesentlicher Aspekt 
bei der modularen Erstellung von Programmen ist auch, 
dafi einzelne Programmoduln von anderen Projekten leicht wieder 
verwertet werden konnen. In den vergangenen Jahren hat sich in 
diesem Zusammenhang besonders die Technik des objektorientierten 
Programmierens als vorteilhaft erwiesen. Eine Einfuhrung in die 
Grundlagen und die Namensgebung der objektorientierten 
Programmierung findet sich zum Beispiel in [1] . 

Im Zusammenhang mit der Wiederverwertbarkeit einzelner 
Programmoduln, kommt besonders der Qualitatssicherung dieser 
Programmoduln eine erhohte Bedeutung zu. Den Anf orderungen einer 
besonders fehlerfreien Qualitat einzelner Programmstrukturen wird 
durch besonders entwickelte Testverf ahren Rechnung getragen. Ein 
wesentliches Anliegen des Sof twaretestens ist es, die Qualitat 
der Software im Rahmen der Testabdeckung nachzuweisen . Urn den 
Tester bei seiner Arbeit zu unterstutzen, sind unterschiedlichste 
Testverf ahren denkbar. Man will mit diesen Testverf ahren einen 
durchgehenden Test der Software von einzelnen Programmoduln bis 
zum kompletten System erm6glichen. Insbesondere unterscheidet man 
dabei drei aufeinander aufbauende Tests: den Komponententest , den 
Integrationstest und den Systemtest . Der Komponententest hat das 
Ziel, Fehler in einzelnen Progammkomponenten zu finden. Bei den 
Komponenten handelt es sich herkommlicherweise urn ein oder 
mehrere Moduln, beispielsweise in der objektorientierten 
Programmierung urn Klassen. Der Komponententest wird durch den 
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Datenkomponenten eines auf zuruf enden Objekts scellen dann die 
Testdaten dar. 

Die Technik des objektorientierten Programmierens ist 
vergleichsweise jung. Es gibt deshalb keine technischen Verfahren 
zum testen von Klassen objektorientierter Software. Wurde ein 
Programmierer auf herkommliche Weise eine Klasse testen wollen, 
so muSte er zunachst einen Testfall generieren, d.h. ein Programm 
schreiben, welches aus einer Klasse ein Objekt instanziert . 
Weiterhin muSte er im Vorfeld des Tests Methodenauf ruf e inklusive 
Parameterverte fur dieses Objekt in dieses Programm einarbeiten, 
welche moglichst genau auf die Fehler, die er zu finden hofft, 
abgestimmt waren. Anschliefiend wurde er dieses Programm 
ubersetzen und binden mussen. Nach dem Testlauf wurde dann eine 
Auswertung erfolgen. Falls der Test keine Aussagen uber die 
Funktionsfahgikeit dieser Klasse zulieSe, muSte er den gesamten 
Vorgang erneut durchfuhren. 

Die der Erfindung zugrundeliegende Aufgabe besteht darin, ein 
mteraktives Verfahren zum Testen mindestens einer Klasse eines 
objektorientierten Programmes auf einem Rechner anzugeben. 

Diese Aufgabe wird gemaS den Merkmalen des " Patentanspruchs 1 
gelost . 

Alle ubrigen Weiterbildungen der Erfindung ergeben sich aus den 
Unteranspruchen . 

Besonders vorteilhaft an dem angegebenen Verfahren ist die 
Tatsache, daS Klassen zeitlich vor und unabhangig von ihrer 
eigentlichen Anwendung in objektorientierten Programmen getestet 
werden konnen. 
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Im folgenden wird die Erfindung anhand von Figuren und Beispielen 
weiter erlautert. 



Figur 1 zeigt ein Ausf uhrungsbeispiel eines erf indungsgemaSen 
Verfahrens. Dieses Ausf uhrungsbeispiel kann sich beispielsweise 
auf eine Vermittt lungseinrichtung beziehen. Die 
Programmiersprache, in der der Rechner programmiert wird, sei 
beispielsweise Object CHILL ([2]). 

Figur 2 zeigt als Beispiel ein Programmlisting 

Figur 3 zeigt ein Blockdiagramm eines erf indungsgemaSen 
Verfahrens 

Wie in Figur 1 dargestellt, wird beispielsweise aus einer 
Klassenspezif ikation KS mit Hilfe eines Generators G 
Methodeninformation gewonnen und diese Methodeninf onnation dazu 
benutzt, Variablenspeicher fur die entsprechenden Parameter der 
Methodenaufrufe und die Objekte der Testlingsklassen selbst in 
Form eines Testrahmens TR bereitzustellen . AnschMeSend wird mit 
Hilfe eines Ubersetzers U der Testrahmen TR zusammen mit einem 
Kommandointerpreter KI ubersetzt, wodurch ein fertiges 
Testprogramm TP entsteht. Dieser Kommandointerpreter KI ist 
beispielsweise fur eine Testkommandosprache (die Bef ehlssyntax 
ist weiter hinten in der Beschreibung unter "Eingaben" erlautert) 
entworfen. So kann der Testende einfach Testszenarien erstellen. 
Beispielsweise kann der Kommandointerpreter folgende Befehle 
zulassen : 



<statements> : : = {<command> " ; "} . 

<corm^nd> :: = <control_cmd> | <general_cmd> | <regtest„cmd> | 

<output.cmd> | <modclss_cmd> | <assign.cmd> 
<methcall_cmd> 
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<methcall_cxnd> <objvar> -.- <ident> <parlist>. 

<cmd_keyword> : : « DCL | END | . . .| £LASS_LIST, 



<param> . , 

<ident> 

<idsvar> 

<objvar> 

<string> 

<chars> 
<letter> 
<number> 
<special> 



= <objvar> 



<idsvar> . 



<lecter> { <letter> | <number> | ••_ •• }. 
{<letter> | <number> | <special>}+. 
&" <letter> {<letter> | <number> | •_■ }. 



_ li r it 



{< b eliebiges Zeichen des EBCDIC-Codes 
auSer '>}"■". 

{<beliebiges Zeichen des EBCDIC-Codes 

au£er;>} . 
"A" | "B« | ... | -z-. 



: : = " 0 " I " 1 1 



"g" 



::= <Fur IDS-Variablenamen einschliefilich Kompo- 
nenten erlaubte Sonderzeichen> . 

Beispielsweise werden in erf indungsgemaSen Verfahren zwei Arten 
von variablen unterschieden. Zu. einen die reinen IDS-Variablen 
(IDS: Interakt.ves Debugging System, , die wie gewohnt: deklariert 
und benutzt werden konnen, und zuxn anderen Objekte, die als 

r TeStlingS " ° dSr terklassen ,ber das Ko^ando 

12Uh~QBj deklariert werden. 

Beispielsweise Variable aus mitgebundenen Moduln konnen uber IDS 
una ln Bool-schen Bedingungen von Schleifen und Verzweigungen 
Oder auf der rechten Seite von Zuweisungen mit IDS verwend-t 
werden. Die Verbindung zwischen den nut p^BJ vereinbarten" 
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des Testrahmens mit berucksichtigt worden sein, ansonsten wird 
die Fehlermeldung "UNKNOWN CLASS" ausgegeben. Falls schon ein 
Objekt mit dem angegebenen Namen vereinbart wurde, wird die 
Fehlermeldung "03JECT ALREADY DECLARED" ausgegeben. Der 
Kommandoname DCL_OBJ wurde zur Unterscheidung vom IDS-Kommando 
DCL gewahlt. 

Vereinbarung eines Pointers auf Objekte 

DCL REF OBJ Point ername REF Klassenname 

Der vereinbarte Pointer ist eine IDS-Variable, von deren Existenz 
die Objektverwaltung Kenntnis hat. Die Regeln von IDS sind 
einzuhalten. 

Der Pointermode auf Klassen, von denen Objekte vereinbart werden 
konnen, wird im Testsystem intern deklariert. Beim Loschen von 
Objekten mit dem DIS POSE _OBJ_ Kommando wird gepruft, ob noch mit 
DCL. REF _OBJ fur die Klasse des zu loschenden Objekts vereinbarte 
Pointer auf dieses zeigen (vgl. DISPOSE.OBJ.Kommando) . 

Loschen eines Objekts einer MODULE -Klas s e 

DISPOSE OBJ ObiP>n^mP 

Mit diesem Kommando wird ein zuvor mit DCL_OBJ instantiiertes 
Objekt wieder geloscht. Das Objekt mufi zuvor erzeugt worden sein, 
sonst liegt ein Fehlerfall vor, der mit "OBJECT UNDEFINED" 
gemeldet wird. Falls noch mit DC_LREF_OBJ fur die Klasse des zu 
loschenden Objekts vereinbarte Pointner auf das Objekt zeigen, 
wird das Kommando nicht ausgefuhrt und die Fehlermeldung "OBJECT 
YET REFERENCED BY POINTER" ausgegeben. Es wird aber nicht* 
gepruft, ob noch andere als mit DCL_REF_OBJ vereinbarte Pointer 
auf das Objekt existieren. 
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£HQW_OBJ Objektname 

Das Kommando veranlaSt die Ausgabe der Datenattribute des 
angegebenen Objekts in die Protokolldaten ALL, OUT und auf 
Terminal, falls sie aktiviert sind (dazu Kommando PROTSTATUS) . Es 
wird mit dem IDS-Kommando DISPLAY realisiert . Das Objekt mu£ 
zuvor mit DCL.OBJ erzeugt worden sein, ansonsten wird die 
Fehlermeldung "UNKNOWN OBJECT" ausgegeben. 

Eine weitere Moglichkeit, Objektdaten auszugeben, ist das 
Anzeigen deref erenziert IDS-Pointer, die auf das Objekt zeigen, 
mittels der Kommandos SAY und WRITE. 

Aufruf gewohnlicher Methoden 

Objektname .Methodenname " (" Parameter lis te n ) " 

Bei dem angegebenen Objekt wird die Methode mit den Parametern 
der Parameterliste aufgerufen. Es muS zuvor mmit DCL-OBJ erzeugt 
worden sein. Als Parameter sind nur IDS-Variablen oder Objekte 
(die zuvor in der Kommandosprache vereinbart wurden) zugelassen. 
Bei fehlerhaften Modes wird die Fehlermeldung " PARAMETERMODES DO 
NOT FIT TO METHODNAME" ausgegeben. Wegen moglichen Overloadings 
in den Methoden der Testlingsklasse kann der Mode-Fehler im 
allgemeinen nicht genauer lokalisiert werden. Die Parameter sind 
durch Kommata zu trennen, derart, daS zwischen zwei direkt 
auf einanderf olgenden Parametern je genau ein Komma steht . 
od 

Aufruf einer Methode mit Ergebnis 

Variable : = Ob j ektname .Methodenname "("Parameterliste")" 
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vereinbart sind. Statt Klassennamen kann auch ALL angegeben 
werden, worauf samtliche mit DCL REF OBJ vereinbarcen 
Objektpointernamen ausgegeben werden. Falls fur die Klasse mit 
dem angegebenen Namen keine Objektverwaltung generiert wurde, 
wird die Fehlermeldung "UNKNOWN CLASS" ausgegeben. 

Information liber Klassen 

CLASS LIST 

Dieses Kommando veranlaEt die Ausgabe aller Klassennamen, fur die 
eine Objektverwaltung generiert wurde . 

Die hier gemachten Ausfuhrungen sind nur als Beispiel fur eine 
Ausf uhrungsf orm des erf indungsgema£en Verfahrens aufzufassen und 
berucksichtigen die spezielle Namensgebung von Obj ect -CHILL . Sie 
sind auf andere objektorientierte Programmiersprachen wie zum 
Beispiel C++, Eiffel, SIMULA oder Smalltalk direkt ubertragbar. 
Es kann beispielsweise ohne Beschrankung der Allgemeinheit auch 
vorgesehen sein, andere Kommandos fur einen Tes t kommando - 
Interprerter vorzusehen. Besonders wichtig ist, daS nur einmal 
ein Testprogramm ubersetzt werden muS und dafi der Tester durch 
das erf indungsgemaSe Verfahren die Moglichk'eit erhalt, samtliche 
fur die Klassentests erf orderliche Testf unkt ionen interaktiv 
auszulosen. Interaktiv kann in diesem Zusammenhang auch bedeuten, 
daS er Testkommandodateien generiert und diese startet- und mit 
entsprechenden Abbruchkriterien versieht. 

In Figur 2 ist ein Testbeispiel des erf indunsgemafien Verfahrens 
als Programmlisting aufgefuhrt. Es enthalt die Klassen- 
vereinbarung und die entsprechenden Kommandos fur den Testin- 
terpreter . 

In diesem Beispiel wird die generische Klasse STAGENLS uber ihre 
zwei Auspragungen STAINTLS und STATEXLS getestet . 



/ 

/ 
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4 



EINGABEN 




4.1.1 Allgemeine Konventionen 



Die Kommandosprache des Testsystems ist an CHILL und an IDS 
angelehnt. Dies bedeutet insbesondere , da3 

- der gleiche Zeichensatz verwendet wird, d.h. fur Schliisselworte^ 
und Bezeichner nur GroGbuchstaben zulassig sind, 

- alle Kommandos durch ein Semikolon abgeschlossen werden, 

- Kommentare wie Leerzeichen (Blanks) behandelt werden, 

- Blanks zwischen Schliisselwortern oder Bezeichnern angegeben 
werden. mussen, wahrend sie zwischen Operatoren wegbleiben 
konnen. 



Zusatzlich werden folgende Festlegungen getroffen: 

- Zeilentrenner werden wie Blanks behandelt, d.h. bei einem 
mehrzeiligen Kommando wird nach dem 80. Zeichen (entspricht 
einer MVS-Zeile) ein Blank eingefugt. Somit endet ein Wort 
spatestens am Zeilenende. 

- Die im folgenden aufgefiihrten Langen verstehen sich als 
Maximalwerte. 

Bezeichner sind maximal 31 Zeichen lang.. 

Strings konnen eine Zeile (80 Zeichen) lang sein, wenn sie mit 
den Kommandos SAY bzw. WRITE ausgegeben werden. 

Boolesche Bedingungen in Schleifen und Verzweigungen , Ausdrucke 
und Variablendeklarationen diirfen 190 Zeichen nicht iiberschrei- 
ten, da diese mit Hilfe von IDS ausgewertet bzw. deklariert 



- Erfolgreich eingegebene Kommandos werden nicht explizit 
quittiert, sondern es wird die Eingabe des nachsten Kommandos 
erwartet. Ausnahmen hierzu bilden lediglich die Kommandos 
END, REGTESTSTART und REGTESTEND. 

- Fehlerhafte Kommandos werden durch entsprechende Meldungen ange- 
zeigt, wobei implizite Fehlerkorrekturen nicht durchgefvihrt 
werden. Nach einem fehlerhaften Kommando erwartet der Interpre- 
ter das nachste Kommando im Terminalmodus , d.h. Komraandodateien 
werden unmittelbar nach einem Fehler verlassen. Tritt der Fehler 
m Kontrollstrukturen auf, werden diese genau wie das Kommando 
abgebrochen. .Weitere Kommandos in der gleichen Zeile werden 
ignoriert. -Fehlerhafte "Kommandos wahrend des. Regressionstestes" 
fiihren zum Abbruch des Regressionstests . (vgl. Kapitel 6) 



werden 
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- Das Metasymbol '.' zeigt das Ende einer Regel an. 

- Anstelle aes Non-Terminal-Symbols <chars> wird eine beliebiq- 
Zeichenfolge erwartet, die z Ur Auswerrung an IDS ubergeben wird 
Diese Zeichenfolge wird vom Testsystem nicht syntaktSSh 

analysiert. 



Grammatik der Kommandosprache fiir den MODULE -Kl as sen-Test : 



<statements> 
<conunand> 

<control_cmd> 
<general_cmd> 



<output_cmd> 
<regtest_cmd> 
<modclss cmd> 



<assign_cind> 

<methcall_cmd> 

<cmd_keyword> 

<parlist> 



: = { <command> " ; » } . 

:= <control_cmd> | <general_cmd> | <regtest_cmd> 
<output_cmd> | <itiodclss_cmd> | <assign cmd> I 
<methcall_cmd> ~ 

:= DO WHILE <chars> »;» <statements> OD I 
IF <chars> THEN <statements> 

[ELSE <statements>] FI . 

:= DCL <chars> | 
END | 

PROTSTATUS | 

PROTOCOL [TERM] [ALL] [INP] [OUT] I 
INPUT (INP1 | INP2 | INP3 I INP4 I INP5 ) I 
RETURN | 
EXIT | 

HELP [ <cmd_keyword> ] | 
IDS_ON. 

:= SAY (<idsvar> | <string>) | 
WRITE (<idsvar> | <string>) . 

:= REGTEST START | 
REGTEST END . 

:= DCL _OBJ <objvar> <ident> [<parlist>] | 
DCL_REF_OBJ <idsvar> REF <ident> I 
DISPOSE_OBJ <objvar> | 
ASSIGN_REF_OBJ <objvar> <idsvar> | 
ASSIGN_DEREF_PTR <idsvar> <objvar> I 
SHOW JDBJ <objvar> 
OBJ LIST (<ident> ALL) | 
OBJ REF LIST (<ident> | ALL) | 
CLASS LIST . 

:= <idsvar> " :=" ( <methcall_cmd> | <chars>) | 
<objvar> ":=" (<objvar> | <methcall_cmd> ) . 

:= <objvar>" . "<ident> <parlist>. 

:= DCL | END | ... | CLASS LIST . 

:= »■(» [ <param> { " , " <param> ) ] ")". 



<param> 



= <objvar> | <idsvar>. 
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FIG 2 



Member 1) 

STAGENLS : GENERIC 

SYNMODE ELEMMODE = ANY_ASSIGN; 

MODULE CLASS 

GRANT POP, TOP, ISEMPTY, PUSH PREFIXED STAGENLS; 
STAGENLS :CONSTR(); END STAGENLS; 

POP : PROC ( J ; 
END POP; 

TOP : PROC() RETURNS (ELEMMODE) ; 
END TOP; 

PUSH : PROC (EL ELEMMODE) ; 
END PUSH; 

ISEMPTY : PROC() RETURNS (BOOL) ; 
END ISEMPTY; 

SYNMODE STACKPTRMODE = REF STACKELMODE; 
SYNMODE STACKELMODE = STRUCT ( 

EL ELEMMODE, 

NEXT STACKPTRMODE) ; 
DCL ANCHOR STACKPTRMODE; 

END STAGENLS; 

Der BODY von STAGENLS ist nicht Eingabe fur den 
Testrahmengenerator J 



Member 2 ) 

STAINTLS : MODULE CLASS *= STAGENLS 

ACT_GEN_PART 

SYNMODE ELEMMODE = INT; 

END STAINTLS; 



Member 3) 



STATEXLS : MODULE CLASS = STAGENLS 

SEIZE TEXMODE; 

ACT_GEN_PART 

SYNMODE ELEMMODE = TEXMODE; 
END STATEXLS; 
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(54) Title: PROCESS FOR TESTING AT LEAST ONE CLASS OF AN OBJECT-ORIENTED PROGRAM ON A COMPUTER 

(54) Bezeichnung: VERFAHREN ZUM TESTEN MJNDESTENS EINER KLASSE EINES OBJEKTORIENTIERTEN PROGRAMMES 
AUF EINEM RECHNER 

i (57) Abstract 

The invention provides for the first time a process for testing 
classes of an object-oriented program. Classes are tested by causing 
the tests interactively to input test commands with their method calls. 
It is also possible to check the test results interactively. Testability is 
obtained in that the necessary call parameters are found beforehand for 
all the methods permitted in the class and precautions are taken in the 
computer store to store and alter the possible parameters. The advantage 
is that testing can be performed interactively and not, as previously, in 
that the test program had to be once more corrected, translated and fixed 
after test evaluation, which took a great deal of time. The invention can 
advantageously be used in the development of communication software. 



(57) Zusammenfassung 

Mit der Erfindung wird crstmals ein Verfahren zum Tcsten von 
Klassen eines objektorientierten Programmes zur VerfUgung gestellL 
Klassen werden getestet, indem vom Tester Testkommandos mit 
denen Methodenaufrufe mdglicb sind, interaktiv eingegeben werden. 
die Obeipriifung der Testergebnisse ist ebenfalls interaktiv mdglich. 
Erreicbt wird die Testbarkeit dadurch, dafi vorab ftlr alle in der 
Klasse erlaubten Methodeo, die erforderlichen Aufrufparameter ermitelt 
werden, und dafi im Rechnerspeicher Vorkehrungen getroffen werden, 
um die moglichen Parameter abzuspeichem und zu verandcrn. Der 
Voneil besteht darin, dafi interaktiv getestet werden kann, und nicht, wie 
bisher ubtich das Testprogramm nach der Tescauswertung zeitaufwehdig 
craeut korrigiert Ubersetzt und gebunden werden muB. Vorteilhaft 
kann die Erfindung bei der Entwicklung von Kommunikations- Software 
eingesettt werden. 
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Verfahren zum Testen mindestens einer Klasse eines 
objektorientierten Programmes auf einem Rechner 

Mit dem zunehmendem Umfang von Systemldsungen im Rahmen von 
industriellen Grofiprojekten, wachst auch der Beitrag den die 
Software zur Losung liefert. Damit man grofie Sof twareprojekte 
effizient abwickeln kann, hat es sich als vorteilhaft erwiesen, 
diese Projekte in Teilprojekte zu unterteilen und einzelne 
Programme modular zu erstellen. Ein nicht unwesentlicher Aspekt 
bei der modularen Erstellung von Programmen ist auch, 
dafi einzelne Programmoduln von anderen Projekten leicht wieder 
verwertet werden konnen. In den vergangenen Jahren hat sich in 
diesem Zusammenhang besonders die Technik des objektorientierten 
Programmierens als vorteilhaft erwiesen. Eine Einfuhrung in die 
Grundlagen und die Namensgebung der objektorientierten 
Programmierung findet sich zum Beispiel in [1] . 

Im Zusammenhang mit der Wiederverwertbarkeit einzelner 
Programmoduln, kommt besonders der Qualitatssicherung dieser 
Programmoduln eine erhohte Bedeutung zu. Den Anf orderungen einer 
besonders fehlerfreien Qualitat einzelner Programmstrukturen wird 
durch besonders entwickelte Testverf ahren Rechnung getragen. Ein 
wesentliches Anliegen des Sof twaretestens ist es, die Qualitat 
der Software im Rahmen der Testabdeckung nachzuweisen . Urn den 
Tester bei seiner Arbeit zu unterstutzen, sind unterschiedlichste 
Testverf ahren denkbar. Man will mit diesen Testverf ahren einen 
durchgehenden Test der Software von einzelnen Programmoduln bis 
zum kompletten System erm6glichen. Insbesondere unterscheidet man 
dabei drei aufeinander aufbauende Tests: den Komponententest , den 
Integrationstest und den Systemtest. Der Komponententest hat das 
Ziel, Fehler in einzelnen Progammkomponenten zu finden. Bei den 
Komponenten handelt es sich herkommlicherweise um ein oder 
mehrere Moduln, beispielsweise in der objektorientierten 
Programmierung um Klassen. Der Komponententest wird durch den 
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Datenkomponenten eines auf zuruf enden Objekts stellen dann die 
Testdaten dar. 

Die Technik des objektorientierten Programmierens ist 
vergleichsweise jung. Es gibt deshalb keine technischen Verfahren 
zum testen von Klassen objektorientierter Software. Wurde ein 
Programmierer auf herkommliche Weise eine Klasse testen wollen, 
so mufSte er zun&chst einen Test fall generieren, d.h. ein Programm 
schreiben, welches aus einer Klasse ein Objekt instanziert . 
Weiterhin mufcte er im Vorfeld des Tests Methodenauf ruf e inklusive 
Parameterwerte fur dieses Objekt in dieses Programm einarbeiten, 
welche moglichst genau auf die Fehler, die er zu finden hofft, 
abgestimmt waren. AnschlieSend wurde er dieses Programm 
ubersetzen und binden mussen. Nach dem Testlauf wurde dann eine 
Auswertung erfolgen. Falls der Test keine Aussagen uber die 
Funktionsf ahgikeit dieser Klasse zulieSe, muSte er den gesamten 
Vorgang erneut durchfuhren. 

Die der Erfindung zugrundeliegende Aufgabe besteht darin, ein 
interaktives Verfahren zum Testen mindestens einer Klasse eines 
objektorientierten Programmes auf einem Rechner anzugeben. 

Diese Aufgabe wird gemaS den Merkmalen des Patentanspruchs 1 
gelost . 

Alle ubrigen Weiterbildungen der Erfindung ergeben sich aus den 
Unteranspruchen . 

Besonders vorteilhaft an dem angegebenen Verfahren ist die 
Tatsache, daS Klassen zeitlich vor und unabhangig von ihrer 
eigentlichen Anwendung in objektorientierten Programmen getestet 
werden konnen . 
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Im folgenden wird die Erfindung anhand von Figuren und Beispielen 
weiter erlautert. 

Figur 1 zeigt ein Ausf uhrungsbeispiel eines erf indungsgemaSen 
Verfahrens. Dieses Ausf uhrungsbeispiel kann sich beispielsweise 
auf eine Vermitttlungseinrichtung beziehen. Die 
Programmiersprache, in der der Rechner programmiert wird, sei 
beispielsweise Object CHILL ([2]). 

Figur 2 zeigt als Beispiel ein Programmlisting 

Figur 3 zeigt ein Blockdiagramm eines erf indungsgemafcen 
Verfahrens 

Wie in Figur 1 dargestellt, wird beispielsweise aus einer 
Klassenspezif ikation KS mit Hilfe eines Generators G 
Methodeninf ormation gewonnen und diese Methodeninf ormation dazu 
benutzt, Variablenspeicher fur die entsprechenden Parameter der 
Methodenauf ruf e und die Objekte der Testlingsklassen selbst in 
Form eines Testrahmens TR bereitzustellen . Anschliefiend wird mit 
Hilfe eines Ubersetzers U der Testrahmen TR zusammen mit einem 
Kommandointerpreter KI ubersetzt, wodurch ein fertiges 
Testprogramm TP entsteht. Dieser Kommandointerpreter KI ist 
beispielsweise fur eine Testkommandosprache (die Bef ehlssyntax 
ist weiter hinten in der Beschreibung unter "Eingaben" erlautert) 
entworfen. So kann der Testende einfach Testszenarien erstellen; 
Beispielsweise kann der Kommandointerpreter folgende Befehle 
zulassen : 

<statements> ::= {<command> ";"}. 

<command> ::= <control.cmd> | <general_cmd> | <regtest_cmd> | 

<output_cmd> | <modclss_cmd> | <assign_cmd> 
<methcall_cmd> 
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<methcall_cmd> ::= <objvar> n . " <ident> <parlist> 



<cmd_keyword> ::= DCL | END | . . .| £LASS_LIST. 



<param> - 



= <objvar> | <idsvar>. 



<ident> ::= <letter> { <letter> I <number> | H _ " }. 

<idsvar> "%" {<letter> I <number> I <special>}+. 

<objvar> <letter> {<letter> | <number> | }. 

<string> ::= " {<beliebiges Zeichen des EBCDIC-Codes 

aufier ■>}" ■ " . 

<chars> ::= {<beliebiges Zeichen des EBCDIC-Codes 

auSer ; >} . 

<letter> ::= "A 11 | M B" | ... | "Z n . 
<number> :: = "O" | "1" | . . . | "g" . 

<special> :: = <Fur IDS-Variablenamen einschliefilich Kompo- 

nenten erlaubte Sonderzeichen> . 



Beispielsweise werden im erf indungsgemafien Verfahren zwei Arten 
von Variablen unterschieden . Zum einen die reinen IDS-Variablen 
(IDS: Interaktives Debugging System), die wie gewohnt deklariert 
und benutzt werden konnen, und zum anderen Objekte, die als 
Instanzen von Testlings- oder Parameterklassen uber das Kommando 
DCL -OBJ deklariert werden. 

Beispielsweise Variable aus mitgebundenen Moduln konnen uber IDS. 
und in Bool'schen Bedingungen von Schleifen und Verzweigungen 
oder auf der rechten Seite von Zuweisungen mit IDS verwendet 
werden. Die Verbindung zwischen den mit E£li-QBJ vereinbarten 
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des Testrahmens mit berucksichtigt worden sein, ansonsten wird 
die Fehlermeldung " UNKNOWN CLASS " ausgegeben. Falls schon ein 
Objekt mit dem angegebenen Namen vereinbart wurde, wird die 
Fehlermeldung "OBJECT ALREADY DECLARED" ausgegeben. Der 
Kommandoname DCL_OBJ wurde zur Unterscheidung vom IDS-Kommando 
DCL gewahlt. 

Vereinbarung eines Pointers auf Objekte 

DCL REF OBJ Pointername REF Klassenname 

Der vereinbarte Pointer ist eine IDS-Variable, von deren Existenz 
die Objektverwaltung Kenntnis hat. Die Regeln von IDS sind 
einzuhalten. 

Der Pointermode auf Klassen, von denen Objekte vereinbart werden 
konnen, wird im Testsystem intern deklariert . Beim Loschen von 
Objekten mit dem DISPOSE_OBJ_Kommando wird gepruft, ob noch mit 
DCL_REF_OBJ fur die Klasse des zu loschenden Objekts vereinbarte 
Pointer auf dieses zeigen (vgl. DISPOSE. OBJ. Kommando) . 

Loschen eines Objekts einer MODULE-Klasse 

DISPOSE OBJ ObHfikrn*mP 

Mit diesem Kommando wird ein zuvor mit DCL_OBJ instantiiertes 
Objekt wieder geloscht. Das Objekt mufi zuvor erzeugt worden sein, 
sonst liegt ein Fehlerfall vor, der mit "OBJECT UNDEFINED" 
gemeldet wird. Falls noch mit DC.LREF.OBJ fur die Klasse des zu 
loschenden Objekts vereinbarte Pointner auf das Objekt zeigen, 
wird das Kommando nicht ausgefuhrt und die Fehlermeldung "OBJECT 
YET REFERENCED BY POINTER" ausgegeben. Es wird aber nicht 
gepruft, ob noch andere als mit DC L_ REF. OBJ vereinbarte Pointer 
auf das Objekt existieren. 
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£HQk2_OBJ Objektname 

Das Kommando veranlafit die Ausgabe der Datenattribute des 
angegebenen Objekts in die Protokolldaten ALL, OUT und auf 
Terminal, falls sie aktiviert sind (dazu Kommando PROTSTATUS) . Es 
wird mit dem IDS-Kommando DISPLAY realisiert . Das Objekt mu£ 
zuvor mit DCL.OBJ erzeugt worden sein, ansonsten wird die 
Fehlermeldung "UNKNOWN OBJECT" ausgegeben. 

Eine weitere Moglichkeit, Objektdaten auszugeben, ist das 
Anzeigen deref erenziert IDS-Pointer, die auf das Objekt zeigen, 
mittels der Kommandos SAY und WRITE. 

Auf ruf gewohnlicher Methoden 

Objektname.Methodenname " ( M Parameter lis te" ) " 

Bei dem angegebenen Objekt wird die Methode mit den Parametern 
der Parameterliste aufgerufen. Es muE zuvor mmit DCL-OBJ erzeugt 
worden sein. Als Parameter sind nur IDS-Variablen oder Objekt e 
(die zuvor in der Kommandosprache vereinbart wurden) zugelassen. 
Bei fehlerhaften Modes wird die Fehlermeldung " PARAMETERMODES DO 
NOT FIT TO METHODNAME" ausgegeben . Wegen moglichen Overloadings 
in den Methoden der Testlingsklasse kann der Mode-Fehler im 
allgemeinen nicht genauer lokalisiert werden. Die Parameter sind 
durch Kommata zu trennen, derart, daS zwischen zwei direkt 
auf einanderf olgenden Parametern je genau ein Komma steht . 
od 

Auf ruf einer Methode mit Ergebnis 

Variable : = Objektname.Methodenname " { "Parameterliste" ) M 
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Es gelten die gleichen Regeln wie beim Aufruf gewohnlicher 
Methoden (s.o. ) . 

Die Variable, der das Ergebnis zugewiesen wird, mufi eine IDS- 
Variable oder ein zuvor mit DCL.OBJ vereinbartes Objekt passenden 
Modes sein, sonst wird eine Fehlermeldung ausgegeben. 

Zuweisung mit Objekt en 

Objl := 0bj2 

Den Datenkomponenten von Objl werden die entsprechenden Werte von 
Obj2 zugewiesen. Die beiden Objekte mussen zuvor mit DVL.OBJ 
vereinbart worden und von der selben Klasse sein, sonst wird die 
Fehlermeldung "UNKNOWN OBJECT Objektname" bzw. 11 MODE -MIS SMATCH " 
ausgegeben. 

Information iiber Objekte 

OBJ LIST Kl ass enname 

Dieses Kommando veranlaSt die Ausgabe der Namen aller Objekte, 
die aktuell fur die angegebene Klasse vereinbart sind. Statt 
Klassenname kann auch ALL angegeben werden, worauf zu samt lichen 
Klassen, fur die eine Obj ektverwaltung existiert, die Objektnamen 
ausgegeben werden. Falls fur die Klasse mit dem angegebenen Namen 
keine Obj ektverwaltung generiert wurde, wird die Fehlermeldung 
"UNKNOWN CLASS " "ausgegeben. 

Information iiber Objektpointer 

OBJ REF LIST Klassenname 

Dieses Kommando veranlaSt die Ausgabe aller Pointernamen, die 
aktuell zur angegebenen Klasse mit dem Kommando DC L_R E F__OB J 
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Ubergabe der Adresse eines Objekts 

ASSIGN REF OBJ Objektname IDS-Variable 

Das Kommando schreibt die Adresse des angegebenen Objekts in die 
IDS-Variable . Diese muS mit DCL_REF_OBJ als Pointer auf die 
Klasse des angegebenen Objekts vereinbart worden sein, sonst wird 
die Fehlermeldung "UNKNOWN IDS-POINTER" ausgegeben. (Kein 
Polymorphismus fur die mit DCL_REF_OBJ Pointer!). Das Objekt muS 
zuvor mit DCL.OBJ erzeugt worden sein, sonst wird die 
Fehlermeldung " UNKNOWN OBJECT" ausgegeben. 

Nach dem Kommando zeigt die IDS-Variable auf das Objekt. Durch 
dieses Kommando wird fur den Tester die Verbindung zwischen IDS 
und den Objekten der Kommandosprache hergestellt. 

Ubergabe der Daten eines deref enzierten Pointers 

AS£IGN_DEREF_ PTR IDS-Variable Objektname 

Das Kommando kopiert die Daten des Obekts, auf das der Pointer 
zeigt, in das angegebene Objekt. Durch dieses Kommando wird fur 
den Tester die Verbindung zwischen IDS und den Objekten der 
Kommmandosprache hergestellt. 

Die IDS-Variable mufi mit DCL.REF.OBJ als Pointer auf die Klasse 
des angegebenen Objekts vereinbart worden sein, sonst wird die 
Fehlermeldung "UNKNOWN IDS-POINTER" ausgegeben. (Kein 
Polymorphismus fur die mit DCL.REF_OBJ vereinbarten ! ) . Die IDS- 
Variable mufi auch tatsachlich auf ein Objekt dieser Klasse 
zeigen. Dies kann vom Testsystem nicht uberpruft werden! Das 
angegebene Objekt muS zuvor mit DVL-OBJ erzeugt worden sein, 
sonst wird die Fehlermeldung " UNKNOWN OBJECT" ausgegeben. 



Ausgabe der Daten eines Objekts 
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Objekten mit IDS wird durch IDS-Pointer beispielsweise vom Mode 
"REF Testingsklasse" (mit DCL.REF.OBJ zu vereinbaren) und den zwei 
Kommandos ASS IGN ref _ OBJ und ASSIGN_DEREF_PTR hergestellt. Bei- 
spielsweise werden Operatoren der Testsystem Kommandosprache auf 
IDS-Operatoren abgebildet. 

Im erf indungsgemafien Verfahren konnen beispielsweise folgende 
Befehle zu Objektbearbeitung vorgesehen sein, die vom Testenden 
interaktiv eingegeben werden und die eine hohe Flexibilitat beim 
Test gewahrleisten .Die Testeingaben durch den Testenden und die 
von ihm getatigten Aufrufe werden sinnvollerweise gesondert 
verwaltet. Beispielsweise ist eine Objektverwaltung vorgesehen, 
um die Zuweisung von Testobjekten in der Kommandosprache zu 
Rechner-Objekten sicherzustellen. Weiterhin kann auch vorteilhaft 
eine Auf ruf bearbeitung vorgesehen sein, welche die Konsistenz von 
Test-Methodenauf ruf en mit hardwareseitig ablaufenden Programmen 
sicherstellt . Es ist dazu nicht erf orderlich, das Testprogramm 
neu zu generien. 

Konunandos zur Objektbearbeitung 

Vereinbarung eines Objekts einer MODULE -Klasse 

DCL OBJ Objektname Klassenname " ( "Parameterliste" ) n 

Mit diesem Kommando wird ein Objekt auf Ebene der Kommandosprache 
bereitgestellt . "Die Parameterliste gibt die Parameter fur den 
Konstruktorauf ruf an. Sie kann entf alien, dann wird der 
Standardkonstruktor aufgerufen. Ansonsten gelten fur sie die 
gleichen Regeln wie beim Methodenauf ruf . 
Der Objektname mufi aus dem Zeichen & gefolgt von einem 
GroEbuchstaben und dann hochstens noch 29 GroSbuchstaben, Ziffern 
oder Unterstrichen bestehen, ansonsten wird die Fehlermeldung 
"ILLEGAL OBJECTNAME" ausgegeben. Die Klasse muS bei der Erzeugung 
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<control_cmd : : = Do WHILE <chars> " ; " <statement s> OD 

IF <chars> THEN <statements> 

[ELSE <statements>] FI . 

<general-cmd> ::= DCL <chars> | 

END | 

PROTSTA TUS | 

PROTOCOL [TERM] [ALL] [INP] [OUT] | 
INPUT (INP1 | INP2 | INP3 | INP4 | INP5) | 
RETURN | 
EXIT I 

HELP [<cmd_keyword>] 
IDS. ON. 



<output_cmd> ::= SAY (<idsvar> | <string>) | 

WRITE (<idsvar> | <string>) . 

<regtest„cmd> ::= REG TES TSTART | 

REG TESTEND 



<modclss-cmd> :: = JQCL-QBJ <objvar> <ident> [<parlist>] .| 

ECL-EEF.QBJ <idsvar> REF <ident> | 
£I£POS£_QBJ objvar | 
AS S IGN_ REF _ QB J <objvar> <idsvar> | 
■ A££IGN_I>EREF_PTR <idsvar> <objvar> | 
SHOW o bj <objvar> | 
QBJ_LIS1 (<ident> | ALL | 
OBJ REF LIST (<ident>) | ALL) | 

£LASS_LISL 



<assign-cmd> 



= <idsvar> " : = '* (methcall.cmd> | <chars>) | 
<objvar> " : = '* (<objvar> | <methcall.cmd>) . 
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Besonders vorteilhaft an der Anwendung des erf ihdungsgemaSen 
Verfahrens ist die Tatsache, .daS bereits im Vorfeld des Tests 
alle fur den Test mafigeblichen KenngroSen erfafit werden und daS 
das Testprogramm nur einmal ubersetzt und gebunden werden muS. 

Um das Zusammenspiel auch mehrerer Klassen sinnvoll testen zu 
konnen, ist im erf indungsgemafien Verfahren gunstigerweise 
vorgesehen, die Methodeninf ormation aller am Test beteiligten 
Klassen fur die in der externen Methodenschnittstelle der 
beteiligten Klassen definierten Methoden zu gewinnen. 

Besonders vorteilhaft ist am erf indungsgemafien Verfahren, daS es 
im Vorfeld eine Speicherzuweisung fur die Objektinitialisierung 
oder Methodenauf ruf e vorsieht. 

Eine gunstige Form der Speicherzuweisung geschieht beispielsweise 
uber pointer, die dann wahrend des Testbetriebs umdefiniert 
werden konnen. 

Weiterhin ist es gunstig, da£ das erf indungsgemaSe Verfahren 
einen Zugriff auf obj ektinterne Datenkomponenten vorsieht, da 
diese normalerweise fur einen Tester wegen des, beim 
objektorientierten Programmieren ublichen, Data Hidings nicht 
zuganglich sind. 

•Weiterhin ist es beim angegebenen Verfahren gunstig, daS ein 
Debugger angeschlossen ist, sodafi beim Test entdeckte Fehler 
sofort mit zusatzlicher Zuhilfenahme des Debuggers analysiert und 
lokalisiert werden konnen. 

Um die Funktionsweise einer Klasse moglichst vollstandig Testen 
zu konnen, sieht das erf indungsgemafie Verfahren sinnvollerweise 
auch eine Gewinnung der Methodeninf ormation fur generische und 
vererbende Klassen vor. 
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Integrationstest , mit dessen Hilfe Fehler an den Schnittstellen 
und in der Kommunikation zwischen den getesteten Komponenten 

entdeckt werden, erganzt. Zum AbschluS kann ein Systemtest 
durchgefuhrt werden, welcher einen Test aus Kundensicht darstellt 
(z.B. der Test einer kompletten vermittlungstechnischen Anlage) . 
Er hat das Ziel die Stabilitat des gesamten ( Programm- ) Systems 
unter "Last", d.h. realen bis extremen Bedingungen, zu testen. 

Im Rahmen der Technik des objektorientierten Programmierens wird 
der Komponententest durch ein Testverf ahren fur Klassen 
bereitgestellt . Sinnvollerweise beginnt man mit dem Testen bei 
einzelnen Programmkomponenten, d.h. den Klassen. Setzt man beim 
Test eines Programmes auf nicht ausgetestete Klassen auf, so 
werden Fehler, die bei der Klassenimplementierung gemacht wurden, 
nicht Oder nur sehr viel schwerer gefunden und entsprechend 
schwer behoben. Der Grund dafur liegt neben der schlechten 
Uberschaubarkeit des gesamten Programmes in der Vermischung 
dieser funktionalen Fehler, mit denen, die beim Zusammenspiel der 
einzelnen Objekte auftreten (Komunikations-bzw. Schnittstellen- 
fehlern) . Ein weiterer wesentlicher Grund fur gut ausgetestete 
Klassen ist die daraus resultierende gesteigerte Bereitschaf t , 
diese Klassen wieder zu verwenden. Qualitativ schlechte Software 
eignet sich of f ensichtlich .nicht zur Wiederverwendung . 

Klassen sind als Testlinge in der Regel fur sich alleine nicht 
ablauf fahig und "damit ohne zusatzlichen Aufwand auch nicht mit 
einem Debugger eines Betriebssystems zu debuggen. Da diese 
Testlingsklassen nur Programmstrukturen darstellen, ist es 
zwingend erf orderlich, fur ihren Test Objekte aus ihnen 
abzuleiten. Sie werden dann getestet, indem bei den Objekten 
entsprechende Methoden aufgerufen und ausgefuhrt werden. Die 
Parameter eines Methodenauf ruf s zusammen mit den Werten der 
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Patent anspruche 

1. Verfahren zum Testen mindescens einer Klasse eines objekto- 
rientierten Programmes auf einem Rechner, 

a) bei dem aus mindestens einer Klassenspezif ikation 
eine Methodeninf ormation uber mindestens eine Methode 
und deren zugehorige Auf rufparameter gewonnen wird, 

b) bei dem mit Hilfe der Methodeninformation ein Bestandteil 
ernes Testprogramms erzeugt wird, welcher mindestens ein= 
Zuweisung von beim Testen erf orderlichen Rechnerbetriebsmitteln 
sicherstellt, 

c) bei dem ein Testprogramm erzeugt wird, das als einen 
Bestandteil einen Kommandointerpreter enthalt, welcher von ein 
Testenden eingegebene Testkommandos interpretiert , und das als 
einen weiteren Bestandteil den unter b) erzeugten Bestandteil des 

Testprogramms enthalt 

d) und bei dem das Testprogramm mit Hilfe der Testkommandos zum 
Testen der Klasse verwendet wird. 

2. Verfahren nach Anspruch 1, bei dem die Methodeninformation 
zumxndest fur alle uber eine externe Methodenschnittstelle 
exportierten Methoden, jeder einzelnen von gemeinsam zu testender 
Klassen gewonnen wird. 

3. Verfahren nach einem der Anspruche 1 oder 2, bei dem ein 
Rechnerbetriebsmittel Speicher ist. 

4. Verfahren nach einem der Anspruche 1 bis 3, bei dem die 
Zuweisung der Betriebsmittel uber Pointer erfolgt. 

5. Verfahren nach Anspruch 1, bei dem der Kommandointe-oreter 
mindestens einen in einem Betriebssystem des Rechners v'orhandenen 

Deougger benutzt . 
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4.1.2 Zur Beschreibung der Konmandosprache 

Die Beschreibung der Kommandos ist an die erweitPr-*-- n , 

Form (EBNF) angelehnt, dabei gelten f clg^R^eS? BaCkus ~ Naur - 

- Schliisselworter der Kommandosprache werdon in r^«v, w 
geschrieben. ws^awie weraen in GroBbuchstaben 

- Alternativen werden durch ' I ' dargestellt 7 r- 
Com hat folgende Form: F0RM1 I foIS d h d^ v 

kann ln der Form FORMi oder FiRM2^ingegeEen "r£!T ° °° n 

" g^la^mer;." 699613336 " Werden k6nnen ' in < [< und < ] ' 

2.B.: com hat folgende Form: TEILl r tftt?i * u ^ 

Kommando Com kann in der Form TEILl Tl-rf, „i ' d - h ' das 

dargestellt uerden. ode r TEIL2 TE1L3 

" "°n„erK?°die 0d SkS™; d 5 Para "; tern '. die ^tat werden 
Z.B. kann H^JoJS"^^ ^SS^E.™ 1 d " Namens . 

4.1.3 Die Syntax im tiberblick 



KoLa S Sori d %%r?olS°d S K a x^iie1nt 1 t n ?° 1 Wi ?. die •in«ln m . 
ZusatUich verden fo !,.S£ F^legCng^etrorren^^"**"- 

" rier? e gne1ern y "5°Ko„„en e 2"S die G "»-"* strukto- 

■>■) glfaGt " nen - " erden ln s P it2 <= Kla»mern (<<- £S 

sonstige s y „ b ole in AnfOhruS^SS.^.r^L.^o.... 

Die links vom Metazeichen '■• = > ci . oKa ^ 

konnen durch die rechte Seite erseSt tt^T'l^"^-^^ 
' MV^.^}? geKla^rt 0 !^' "i! d -?- «rde„ d U r f en, 




ammer 
ammerte 



WO 94/14117 



PCT/EP93/03450 



14 



Fur den Generator G dient eine Datei als Eingabe, die drei 
Klassenspezifikationen Member 1). 2) und 3) wis gezeigt als 
Inhalt hat (die Reihenfolge der Members in der Datei ist" ' 
unerheblich! ) . 

Die Klasse STATEXLS importiert aus einem CHILL-Modul TEXMODE De- 
exportierende Modul ist keine Eingabe fur den Generatorlauf . 

Bei diesem Beispiel werden zwei Objektverwaltungsklassen 
OMCL001S und OMCL002S und zwei Auf rufbearbeitungsklassen MCCL001S 
und MCCL002S generiert, weil nur zwei Klassen auftreten, von 
denen Objekte instantiiert und dort Methoden aufgerufen werden 
konnen, namlich STAINTLS und STATEXLS. Bei der oben angegebenen 
Rexhenfolge der Memberdateien gehoren die Klassen ... 001S zu 
STAINTLS und die ... 002S zu STATEXLS 



*igur 3 zeigt anhand eines Blockdiagrammes das Zusaimnenwi rken 
verschiedener Komponenten. bei der Durchfuhrung e^nes 
be.sp.elhaft ausgebildeten erf indungsgemiSen Verf ahrens . 

An oberster Stellebef indet sich hier der Kcanmandointeroretev kt 
welcher Eingaben einer Testperson interpretiert " 
Die Objektverwaltung OV und die Auf rufverwaltung AV stellen di- 
Kons.stenz von Testlingen T mit dem Testszenario eines Testenden 
sxcher Daes gescfiieht, indem sie beispielsweise Speicherbereiche 
xn, Rechner aber Pointer zuweisen, oder diesen Speichebereichen 
namen zuordnen. So gewahrleisten sie den sicheren Ablauf der 
auszufuhrenden Methoden. 
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Es gelten die gleichen Regeln wie beim Aufruf gewohnlicher 
Methoden (s .o . ) . 

Die Variable, der das Ergebnis zugewiesen wird, muS eine IDS- 
Variable oder ein zuvor mit DCL.OBJ vereinbartes Objekt passenden 
Modes sein, sonst wird eine Fehlermeldung ausgegeben. 

Zuweisung mit Objekt en 

Objl := 0bj2 

Den Datenkomponenten von Objl werden die entsprechenden Werte von 
0bj2 zugewiesen. Die beiden Objekte muss en "zuvor mit DVL.03J 
vereinbart worden und von der selben Klasse sein, sonst wird die 
Fehlermeldung "UNKNOWN OBJECT Objektname" bzw. " MODE -MI SSMATCH " 
ausgegeben . 

Information iiber Objekte 

OBJ LIST Kl ass enname 

Dieses Kommando veranlaSt die Ausgabe der Namen aller Objekte, 
die aktuell fur die angegebene Klasse vereinbart sind. Statt 
Klassenname kann auch ALL angegeben werden, worauf zu samtlich~n 
Klassen, fur die eine Objektverwaltung existiert, die Objektname 
ausgegeben werden. Falls fur die Klasse mit dem angegebenen Namen 
kexne Objektverwaltung generiert wurde, wird die Fehlermeldung 
" UNKNOWN CLASS " ausgegeben. 

Information iiber Objektpointer 

£3J_REF_LI£I Klassenname 

Dieses Kommando veranlaSt die Ausgabe aller Pointernamen, die 
aktuell zur angegebenen Klasse mit dem Kommando DCL_REF_OBJ 
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Ubergabe der Adresse eines Objekts 

ASSIGN_REF_QBJ Obj ektname IDS-Variable 

Das Kommando schreibt die Adresse des angegebenen Objekts in die 
IDS-Variable. Diese muG nit DCL.REF.03J als Pointer auf d< e 
Klasse des angegebenen Objekts vereinbart worden sein, sonst wird 
die Fehlermeldung "UNKNOWN IDS -POINTER " ausgegeben (Kein 
Polymorphisms fur die mit DCL.REF.OBJ Pointer!). Das Objekt muS 
zuvor mit DCL.OBJ erzeugt worden sein, sonst wird die 
Fehlermeldung "UNKNOWN OBJECT" ausgegeben. 

Nach dem Kommando zeigt die IDS-Variable auf das Objekt. Durch 

dieses Kommando wird fur d<=n Toehor *i = , 

u £ur aen Tester die Verbmdung zwischen IDS 

und den Objekten der Kommandosprache hergestellt. 
tibergabe der Daten eines deref enzierten Pointers 

ASSIGN_DEREF_PTR IDS-Variable Obj ektname 

Das Kommando kopiert die Daten des Obekts, auf das der Point* ' 
zeigt, m das angegebene Objekt. Durch dieses Kommando wird fu>- 
den Tester die Verbindung zwischen IDS und den Objekten der 
Kommmandosprache hergestellt. 

Die IDS-Variable mu* mit DCL_REF_OBJ als Pointer auf die Klasse 
des angegebenen Objekts vereinbart worden sein, sonst wird die 
Fehlermeldung "UNKNOWN IDS-POINTER" ausgegeben (Kein 
Polymorphismus fur die mit DCL.REF.OBJ vereinbarten ! , . Die IDS- 
Vanable muS auch tatsachlich auf ein Objekt dieser Klasse 
zeigen. Dies kann vom Testsystem nicht uberpruft werden • Das 
angegebene Objekt mu S zuvor mit DVL-OBJ erzeugt worden sein 
sonst wird die Fehlermeldung "UNKNOWN OBJECT" ausgegeben. ' 

Ausgabe der Daten eines Objekts 
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Objekten mit ids wird durch IDS-Pointer beispielsweise vom Mode 
"REF TestingsklasseMmit DCL_REF_OBJ zu vereinbaren) und den * w -< 
Kommandos AS2IGN_EEF.QBJ und ASSIGN. PJ-REF_P.TR hergestellt Bei-" 
spielsweise werden Operatoren der Testsystem Kommandosprache auf 

IDS-Operatoren abgebildet. 

Im erfindungsgemaEen Verfahren konnen beispielsweise folgende 
Befehle zu Obj ektbearbeitung vorgesehen sein, die vom Testenden 
mteraktxv eingegeben werden und die eine hohe Flexibility b^im 
Test gewahrleisten.Die Testeingaben durch den Testenden und die 
von _hm getatigten Aufrufe werden sinnvollerweise gesondert 
verwaltet. Beispielsweise ist eine Objektverwaltung vorges-hon 
urn die Zuweisung von Testobjekten in der Kommandosprache zu 
Rechner-Objekten sicherzustellen . Weiterhin kann auch vorteilhaft 
e.ne Auf ruf bearbeitung vorgesehen sein, welche die Konsistenz von 
Test-Methodenaufrufen mit hardwareseitig ablaufenden Programme ' 
s.cherstellt. Es ist dazu nicht erf orderlich, das Testprogra™ 
neu zu generien. 

KonmiandoB zur Objektbearbeitung 

Vereinbarung eines Objekts einer MODULE - Kla b b e 

CO^QBJ Objektname Klassenname " ( - Parameterliste - ) ■• 

Mit diesem Kommando wird ein Objekt auf Ebene der Kommandosorach* 
berextgestellt. Die Parameterliste gibt die Parameter den " 
Konstruktoraufruf an. Sie kann entfallen, dann wird der ' 
Standardkonstruktor aufgerufen. Ansonsten gelten fur sie die 
gle_chen Regeln wie beim Methodenauf ruf 
Der Objektname muS aus dem Zeichen & gefolgt von einem 
GroSbuchstaben und dann hochstens noch 29 GroSbuchstaben, Ziffern 
cder U terstrichen bestehen, ansonsten wird die Fehler.eldung 
ILLEGAL OB JECTNAME " ausgegeben. Die Klasse mu* bei der Erzeuguna 
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Do WHILE <chars> " ; " <statements> OD 
IF <chars> THEN <statements> 

[ELSE <statements>] FI . 

= DCL <chars> | 
END | 

PR , OTSTA TUS | 

PROTOCOL [TERM] [ALL] [INP] [OUT] | 
INPUT (INP1 | INP2 | INP3 | INP4 | INP5) | 
RETURN | 
EXIT | 

HELP [<cmd_keyword>] 
IDS_ON. 

SAY (<idsvar> | <string>) | 
WRITE (<idsvar> | <string>) . 

= ESQTZST21M2 | 
REG TES TEND 

££L._O.BJ <objvar> <ident> [<parlist>] .| 
J2£L-R.EF_£)BJ <idsvar> REF <ident> | 
P_I£POS£_O.BJ objvar | 
AS_£IGN_REF_O.BJ <objvar> <idsvar> | 
ASSIGN_CEREF_PTR <idsvar> <objvar> | 
SHOW OR.7 <objvar> | 
OBJ i.tst (<ident> | ALL | 
OBJ REF T.TST (<ident>) | ALL) | 
CLASS LIST. 



<idsvar> ••: = •• (methcall_cmd> | <chars>) | 
<objvar> ••: = •• (<objvar> | <methcall.cmd>) . 
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Besonders vorteilhaft an der Anwendung des erf indungsgemafien 
Verfahrens ist die Tatsache, .dafi bereits im Vorfeld des Tests 
alle fur den Test mafigeblichen KenngroSen erfafit werden und dafi 
das Testprogramm nur einmal Qbersetzt und gebunden werden muS. 

Urn das Zusammenspiel auch mehrerer Klassen sinnvoll testen zu 
konnen, ist im erf indungsgemafien Verfahren gunstigerweise 
vorgesehen, die Methodeninf ormation aller am Test beteiligten 
Klassen fur die in der externen Methodenschnittstelle 
beteiligten Klassen definierten Methoden zu gewinnen 



es 



Besonders vorteilhaft ist am erf indungsgemaSen Verfahren, daS 
im Vorfeld eine Speicherzuweisung fur die Objektinitialisierung 
Oder Methodenaufrufe vorsieht. 

Eine gunstige Form der Speicherzuweisung geschieht beisoielsw-is- 
uber pointer, die dann wahrend des Testbetriebs umdefin'iert 
werden konnen. 

Weiterhin ist es gunstig, dafi das erf indungsgemaSe Verfahren 
emen Zugriff auf objektinterne Datenkomponenten vorsieht da 
diese normalerweise fur einen Tester wegen des, beim 

obDektorientierten Programmieren ublichen, Data Hidinas niche 

zuganglich sind. 

Weiterhin ist es beim angegebenen Verfahren gunstig, dafi ein 
Debugger angeschlossen ist, sodafi beim Test entdeckte Fehler 
sofort mit zusatzlicher Zuhilfenahme des Debuggers analysiert und 
lokalisiert werden konnen. 

Urn die Funktionsweise einer Klasse mogiichst vollstandig Testen 
zu konnen. sieht das erf indungsgemaSe Verfahren sinnvollerwe^ se 
auch erne Gewinnung der Methodeninf ormation fur generische und 
vererbende Klassen vor. 
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Integrationstest, mit dessen Hilfe Fehler an den Schnittstellen 
und in der Kommunikation zwischen den getesteten Komponenten 

entdeckt werden, erganzt . Zum AbschluS kann ein Systemtest 
durchgefuhrt werden, welcher einen Test aus Kundensicht darstellt 
(z.B. der Test einer kompletten vermittlungstechnischen Anlage) 
Er hat das Ziel die Stability des gesamten ( Programm- ) Systems 
unter -Last-, d.h. realen bis extremen Bedingungen, zu testen. 

Im Rahmen der Technik des objektorientierten Programmierens wird 
der Komponententest durch ein Testverf ahren fur Klassen 
bereitgestellt. Sinnvollerweise beginnt man mit dem Testen bei 
emzelnen Programmkomponenten, d.h. den Klassen. Setzt man beim 
Test eines Programmes auf nicht ausgetestete Klassen auf, so 
werden Fehler, die bei der Klassenimplementierung gemacht wurden, 
nicht oder nur sehr viel schwerer gefunden und entsprechend 
schwer behoben. Der Grund dafur liegt neben der schlechten 
Uberschaubarkeit des gesamten Programmes in der Vermischung 
axeser funktionalen Fehler, mit denen, die beim Zusammenspiel d-r 
emzelnen Objekte auftreten (Komunikations-bzw. Schnittstellen- 
fehlern). Ein weiterer wesentlicher Grund fur gut ausgetestete 
Klassen ist die daraus resultierende gesteigerte Bereitschaf t , 
diese Klassen wieder zu verwenden. Qualitativ schlechte Sofcwar- 
eignet sich of fensichtlich .nicht zur Wiederverwendung . 

Klassen sind als Testlinge in der Kegel fur sich alleine nicht 
ablauffahig und damit ohne zusatzlichen Aufwand auch nicht mit 
einem Debugger eines Betriebssystems zu debuggen. Da diese 
Testlingsklassen nur Programmstrukturen darstellen, ist es 
zwingend erf orderlich, fur ihren Test Objekte aus ihnen 
abzuleiten. Sie werden dann getestet, indem bei den Objekten 
entsprechende Methoden aufgerufen und ausgefuhrt werden. Die 
Parameter eines Methodenauf ruf s zusammen mit den Werten d=- 
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GE 


Gcorgieo 


GN 


Guinea 


GR 


Griocbenlaad 


HU 


Uogirn 


EE 


Hand 


IT 


lulico 


JP 




KE 


Keaya 


KG 


Kirgiiijuo 


KP 


DcmobmriKhc VoOartpublik Korea 


KR 


Republik Korea 


KZ 


Kaucasuii 


LI 


Liechteosteia 


uc 


Sri Lanka 


LU 


Luxemburg 


LV 




MC 


Monaco 


MB 


"Republik MokUu 


MG 


Madag aakar 


ML 


Mali 


MN 


Moogoki 



MR 


Maurettoiea 


MW 


Malawi 


NE 


Niger 


NX 


Niederiandc 


NO 


Norwegeo 


NZ 


Nexocelaod 


PL 


Poleo 


PT 


Portugal 


RO 


Rumanieo 


RU 


Runiscbe Faderatioo 


SO 


Sudan 


SE 


Scfawcdcn 


SI 


Slowetaeo 


SK 


Slowakri 


SH 


Senega] 


TD 


Tacfaad 


TG 


Togo 


TJ 


Tadscaikistan 


TT 


Trinidad ood Tobago 


UA ■ 


Ukraine 


US 


Vereinigte Slaiiec voo Amerika 


uz 


Utbckzitan 


VN 


Vietnam 



